Computer security system

ABSTRACT

A computer security system for use in a network environment comprising at least a plurality of user computers arranged to communicate over a network, the system comprising a warning message exchange system operable to allow the communication from the user computers of warning messages relating to suspect data identified as a possible security threat; a message counting system operable to maintain a count for every particular piece or set of suspect data based on the number of warning messages communicated relating thereto; and network security means operable to act against any particular piece or set of suspect data for which the count maintained therefor exceeds at least one threshold value

TECHNICAL FIELD

The present invention relates to a computer security system for use in anetworked environment, the system providing a measure of securityagainst suspect data such as computer viruses and the like.

BACKGROUND TO THE INVENTION

Malicious attacks on computer systems have plagued individuals andorganisations for many years. Initially these attacks mostly took theform of viruses in which a rogue program infected a machine via aninfected floppy disk or network location for example. More recently socalled worms and Trojan horses have caused much disruption in which theuser is deceived into running a program via an attachment to an e-mailor a rogue program masquerading as something more innocuous. A largeindustry has grown up around protection from such attacks. Thesecompanies provide anti-virus software that typically resides onindividual machines and monitors the system to check for the presence ofknown viruses. These viruses can take many forms—some more advancedforms are fully polymorphic in that the byte code “signature” isentirely different from one instance of the virus to the next. This isachieved through the use of encryption technology and/or the addition ofspurious and random code to the virus. However, the majority of virusesthat are in the “wild” and the cause of costly disruption to computersystems are relatively simple and can be detected by simple byte-codesignature matching. Many of the current anti-virus programs use justsuch techniques and are successful if the signature of a discoveredvirus can be delivered to machines before the virus strikes.

The operation of such anti-virus programs and systems is well known inthe art, and is usually as follows. A computer user will have installedon their computer an anti-virus program which is provided with adatabase of known computer virus byte-code signatures. The program willtend to run in the background continuously monitoring operationsperformed on the computer, and data received at and transmitted from thecomputer. If the byte-code signature of a known virus stored in theanti-virus program's database is detected by the program, the anti-virusprogram informs the user and takes appropriate action against the data,such as deleting it or storing it in a protected drive.

Such prior approaches tend to suffer from a big problem, however—delay.Even the simplest of viruses and worms may still cause great disruptionat enormous cost to organisations. This is because the process fromdiscovery of a new virus to delivering its signature to all protectedmachines takes too long, and requires an administrative authority suchas the anti-virus program manufacturer (or in some cases anorganisation's IT department) to recognise the problem, take action toidentify the virus's signature, update the anti-virus database, anddistribute the updated database to each user. By the time such asequence of actions is complete the damage has already been done in manycases. What is required is a much more rapid approach—one that canoperate on the same time scales as the spread of the virus and thusprovide much more rapid and cost-saving protection.

Other problems can be caused by the receipt of so-called “spam” emailmessages, which are unsolicited messages sent to a list of recipientsusually advertising a product or service, or frequently includingpornography. The receipt of large amounts of “spam” is analogous to adenial of service attack, in that the spam messages can fill an emailin-box to the extent that the box no longer has any capacity to receivelegitimate messages.

PRIOR ART

There is much work exploring the use of agent technology to providerapid reaction to malicious attack. In this work computer systems areinhabited by a number of agents whose job it is to detect intrusions.One interesting approach aims to draw metaphor from immune systems,which allow an organism to rapidly respond to previously unseen foreignobjects through a “real-time” evolutionary system, as disclosed inArtificial Life IV, Proceedings of the Fourth International Workshop onSynthesis and Simulation of Living Systems, Rodney A. Brooks and PattieMaes, eds., MIT Press, Cambridge, Mass., 1994, pp. 130-139 These kindsof agent systems may prove useful in future security systems, but relyon the successful development and deployment of software agents whichcan detect intrusions. Many other potential future anti-virus systemsare also discussed athttp://www.research.ibm.com/antivirus/SciPapers.htm. In the meantimeuntil the potential of these ideas is exploited, there is still a needfor a system which allows for more rapid prevention of the spread ofcomputer viruses.

One such prior art system which claims to increase response times isthat of the Symantec® Digital Immune System (DIS), which is described athttp://securityresponse.symantec.com/avcenter/reference/dis.tech.brief.pdf.The DIS operates by providing an heuristic search engine whichautomatically identifies possible viruses at either the user's desktop,the server, or the network gateway. A secure channel is then provideddirect to Symantec's security response centre over which the suspectdata can be transmitted. At the security response centre the receiveddata is subject to a number of automatic filters to detect, for example,known clean files, files which are known to return false positives fromthe heuristic search engine, and known virus files. If the suspect datais not filtered out by any of these filters then it is directed to ananalysis program for further analysis and action.

The DIS system therefore allows for the automatic identification, securesubmission, automatic prioritisation, and subsequent analysis of suspectdata, but ultimately still involves a central authority in the loop toanalyse suspect files which make it through the filters. Thus, whilstDIS may improve response times to virus infection through it's automaticfiltering processes, it still relies on a central authority to analysethe suspect data and decide on appropriate action, which must then becommunicated outwards to each user. There is therefore still a need fora system which removes this centralised analysis step to speed theresponse.

SUMMARY OF THE INVENTION

In order to address the above problems, the present invention provides acollaborative computer security system wherein the responsibility fordetection of malicious data such as a computer virus or email addressfrom which spam messages have been received is removed from that of anycentral authority, and is instead placed in the hands of each and everyuser of the network. More particularly, the present invention provides adistributed virus or other malicious data identification system whichallows individual users or software agents running on a user's computerto identify malicious data when they receive it, and to pass a warningmessage concerning the received data to either their peers, or to acentral server. A record is kept either at the server or at each peercomputer as to the number of warning messages communicated concerningany particular piece or set of suspect data, and then appropriatesecurity actions such as issuing warnings to users or blocking thetransmission of the suspect data can be taken once the number of warningmessages communicated from users has passed a certain threshold level.The advantages of the invention are that an organisation's response to acomputer virus intrusion can be much more rapid than was previously thecase where a central authority had to identify the problem and takeaction. Similarly, where spam email messages are being received, theaddress of the sender can be identified and blocked by the users actingcollaboratively.

In view of the above, the present invention provides a computer securitysystem for use in a network environment comprising at least a firstgroup of user computers arranged to communicate over a network, thesystem comprising a warning message exchange system operable to allowthe communication from the user computers of warning messages relatingto suspect data identified as a possible security threat; a messagecounting system operable to maintain a count for every particular pieceor set of suspect data based on the number of warning messagescommunicated relating thereto; and network security means operable toact against any particular piece or set of suspect data for which thecount maintained therefor exceeds at least one threshold value

The primary advantage of the invention is that it allows the securitysystem to work on the same time scales as the spread of the attack. Themore the computer virus or worm spreads the more likely it is thatenough positive identifications are made to allow its signature to beascertained and protection to be installed. This overcomes the problemof traditional security systems where an authority has to learn of thevirus, take action, and then distribute associated protective measuresto the users.

A further advantage of the system is that it allows a lot of informationto be rapidly collected about a computer virus. For example, current“worms” that are “in the wild” are mostly identical at the byte codelevel, however it is likely that in the future this will no longer bethe case, and that there will be variations in different instances ofthe same worm. In such a case, the more instances of the worm that canbe collected the more likely that it will be that suitable protectioncan be devised.

By allowing for individual identification of a worm at each computer bythe user, the present invention allows for multiple instances of thesame virus to be identified and collected.

The suspect data may take any form, but data such as computer viruses,macros, or other executables are particularly envisaged. Alternatively,the suspect data may be, for example, an email address or other networkaddress from which malicious messages or other data has been received.In the description of the embodiments to be made later herein,alternative embodiments may be provided by considering the suspect dataor computer viruses mentioned therein as email address or networkaddress data of addresses from which a user has received spam messages.

The one or more “threshold values” against which the respective countsfor pieces or sets of suspect data are compared may be any value(including zero), and may be fixed or dynamically adaptive. Furthermorethe actual values may be generated by any appropriate function, such asfor example by a random number generator, or as a function of somemetric of accuracy of users in identifying viruses. Furthermore, inother embodiments it is foreseen that the threshold values may notsimply be actual numbers which the respective counts must be greaterthan, but could instead be probabilistic in nature. Furthermore, variouslogical functions or rules can be used for their creation, including forexample, fuzzy logic.

Preferably, the judgement as to whether any piece or set of data presentat any one or more of the user computers is a possible threat isperformed by the respective human user or users of the or each usercomputer. Such an arrangement exploits the massive untapped resourcesand expertise of many computer users, and again allows for a rapidresponse to the spread of a computer virus.

Preferably, the network security means is further operable to comparethe maintained count for a particular piece or set of suspect dataagainst a plurality of different thresholds, and to take differentaction against the data dependent upon which threshold or thresholds areexceeded.

Such an approach allows the computer security systems to have a gradedresponse to a computer virus intrusion, and to take different actionsdepending on the number of warnings received from users. Furthermore, itis also possible to weight warnings from different users, such that awarning from a user who is particularly expert in the field is weightedmore heavily than a casual user of the system.

Preferably, the action taken by the network security means compriseswarning each of the users as to the suspect nature of a particular pieceor set of data. Furthermore, the action may also comprise preventing thetransmission of the particular piece or set of suspect data across thenetwork. Usually, the warning action will be taken when the number ofmessages communicated exceeds a lower threshold than a second thresholdwhich must be crossed in order for the transmission blocking action totake place.

Preferably, the or each warning message comprises at least an identifierof the piece or set of suspect data to which it relates. The identifiermay be the actual piece or set of suspect data itself, or a repeatablygeneratable signature substantially unique to the piece or set of data.By allowing for the collection of such identifiers, the security systemalso provides a means of collecting information on multiple computerviruses, and also on adaptive computer viruses whose byte code signaturemay change in each instantiation on a users machine.

In a preferred embodiment, the computer security system furthercomprises a network server arranged to receive the or each warningmessage communicated from the user computers, and further arranged tohost the message counting system and at least part of the networksecurity system, wherein that part of the network security system hostedby the server is operable to determine the action which should be takenagainst a particular piece or set of suspect data, and to communicate anaction condition indicator indicative of the determined action to eachof the plurality of users.

By using a central server to maintain the warning message counts and toreceive the warning messages themselves, the network traffic generatedby the computer security system is minimised, as users need only send awarning message direct to the server, which can then broadcast warningsabout suspect data as appropriate to all the users.

In another embodiment, the warning messages generated by a user computerare broadcast to every other user computer, and each user computer isfurther arranged to host its own message counting system and networksecurity system operable in accordance with any of the above. Such anapproach represents a “peer-to-peer” system, and provides advantagesthat it is not dependent upon a central server for its operation,thereby presenting a more robust distributed system. Such a peer-to-peersystem has a potential disadvantage, however, in that depending on theexact implementation it may be that the network traffic required tobroadcast the warning messages from each user to every other user isunacceptably high.

To at least partially overcome this problem, in another embodiment thereis provided an inter-group communications system operable to allow thecommunication of warning messages relating to suspect data identified asa possible security threat from the first group of user computers to oneor more other groups of other user computers. By splitting the usercomputers intro groups, the number of warning messages which arerequired to be transmit is substantially reduced, thereby conservingnetwork signalling bandwidth.

Preferably, the inter sub-set warning messages are transmitted by theinter-sub-set communications system if the number of warning messagescommunicated by the user computers in the sub-set concerning aparticular piece or set of data exceeds at least one threshold value.Preferably the threshold value or values is/are the same as those atwhich the network security system takes action.

In further embodiments, the message counting system is further arrangedto store one or more weighting coefficients relating to one or moreparticular user computers, and to increment the count maintained for aparticular piece or set of suspect data by an amount based upon theweighting coefficient when a warning is received from the one or moreparticular user computers relating to the particular piece or set ofsuspect data

From a second aspect, the present invention also provides a computerreadable storage medium storing one or more computer programs which whenrun on a computer cause the computer to operate in the manner of thecomputer security system as described above. Such a computer securitysystem may provide all the additional features and advantages mentionedpreviously.

BRIEF DESCRIPTION OF THE DRAWINGS

An overview of the operation of the invention, together with adescription of a number of embodiments thereof, presented by way ofexample only, will now be made with reference to the accompanyingdrawings, wherein like reference numerals refer to like parts, andwherein:—

FIG. 1 illustrates a typical network environment in which the computersecurity system of the present invention is intended to operate;

FIG. 2 illustrates a computer storage medium located within each userscomputer, and depicts the programs and data stored thereon in a firstembodiment of the invention;

FIG. 3 depicts a computer storage medium located at a server used withinthe first embodiment of the inventions, and further depicts the programsand data stored thereon;

FIG. 4 is a flow diagram showing the operation steps performed by thewarning creation program stored at the server in the first embodiment ofthe present invention;

FIG. 5 is a flow diagram showing the method steps performed by thewarning receipt program stored at a users computer in the firstembodiment;

FIG. 6 is a flow diagram showing the steps performed by a filter programin either of the embodiments of the invention;

FIG. 7 depicts a computer readable storage medium located at a userscomputer in a second embodiment of the present invention, and furtherdepicts the programs and data stored thereon;

FIG. 8 is a flow diagram of the steps performed by a warning creationprogram in the second embodiment of the present invention;

FIG. 9 is a flow diagram of the steps performed by a warning receiptprogram in the second embodiment of the present invention;

FIG. 10 is a flow diagram illustrating the steps performed by one of thefunctions in both FIGS. 8 and 9; and

FIG. 11 illustrates an organisational architecture of user computerswhich may be used in another embodiment of the invention.

OVERVIEW OF THE OPERATION OF THE INVENTION

The present invention recognises and makes use of the fact that acomputer system is already inhabited by a number of intelligentagents—the users themselves.

In order to summarise the operation of the invention consider an attackby an e-mail “worm” (a type of computer virus such as the “Melissa”virus which was encountered in 2001). A worm is sent to an employee of agiven organisation. With some probability the employee opens the e-mailattachment and unwittingly unleashes the worm that causes some damage tothe individuals machine and propagates itself to a number of othermachines through use of the individuals e-mail system and address book.In each of these cases there is some probability that the user will openthe attachment and further propagate the virus. Thus, the statistics arein the worm's favour—not everyone will open the attachment but it onlytakes a small fraction to do so for the worm to propagate throughout anorganisation's computer system. However, for every user who opens theattachment there are likely to be many more who correctly recognise thee-mail as a potential threat and discard it. Vital information is thusgained in this process—an intelligent agent has successfully detected anintrusion—and it is this information that the present invention exploitsto its full effect. Doing so opens up the potential for the statisticsto be turned against the worm and in favour of the protection system.

Within the invention the user informs the system of the recognition byforwarding the mail or passing the mail or other program to ananti-virus program that is running on that machine, which then passes itto the server (or in an alternative embodiment direct to the user'speers). The signature of the worm is then quickly ascertained and acount kept of the number of warnings received from users about the worm.Once the count reaches a certain threshold the signature of the worm isdistributed to all the other individual machines, who then use thesignature to filter any received data or mail. As an alternative theserver itself could simply filter out all e-mails with such a signature.In either case the technique of allowing users (or user machinesprovided with appropriate software agents) to detect and provide warningof the worm aligns well with the trends in the industry towards peer topeer systems where the vast untapped resources at the edges of thenetwork are beginning to be used to greatly enhance storage andcomputational power for example. The invention is therefore essentiallya peer to peer security system that may tap the vast unused resource ofthe user's knowledge and experience, or the user computer's processingpower.

DESCRIPTION OF THE EMBODIMENTS

Two specific embodiments of the invention will now be described indetail, followed by description of various alterations that may be madeto each to provide additional embodiments. Both main embodiments of theinvention implement a computer security system for use in a networkenvironment. A typical network environment in which the invention may beused is depicted in FIG. 1.

FIG. 1 illustrates a typical local area network (LAN) configuration.Here, a plurality of user computers 15 are connected to a network 10which is another control of a network server 12. The network 10 providestypical network functionality, such as the ability to allow users 15 tocommunicate with each other and with the server over the network. Thenetwork 10 in the invention may be any particular network technology,may be wired or wireless, and may be scaled to any network size orarchitecture known in the art. Therefore, whilst the present inventionis particularly useful for use within individual organisations providedwith a LAN, it may also be used on a wider scale in a metropolitan areanetwork (MAN) or a wide area network (WAN). Within the embodiments, eachof the user computers 15, the network itself 10, and the server 12 areprovided with appropriate equipment and software to permit the usualnetwork communication functions as are known in the art.

Although the above makes reference to the user computers 15 being partof the same network, it should be noted that it is not essential thateach user-computer be located in the same actual network (although thismay be preferable). This is because all that the invention requires isthe ability for any particular user computer to be able to send messageseither to its peers or to a server, and hence all that is required issome message transport mechanism between such parties. Such a messagetransport mechanism may be a single network to which all the usercomputers and servers (where required) are connected, or may be asequence of interconnected networks such as the Internet, with differentuser-computers actually being part of different networks.

Having described the context in which the invention is intended tooperate, a first, preferred, embodiment which represents the best modeof the invention will now be described with reference to FIGS. 2 to 6.

The first embodiment of the invention provides a computer securitysystem wherein identification of suspect data is performed by the usersor suitable software agents installed and running on the user'scomputers at the user's computers themselves, and upon identification ofa suspect piece or set of data a warning message is transmitted from theuser's computer to the network server 12. At the server the number ofwarning messages received about a particular piece or set of data iscounted, and once the count passes a first warning threshold, a warningmessage is broadcast to all users, the message containing a signature ofthe suspect data, such that an anti-virus program located at each user'scomputer can filter incoming data for the suspect data. If furtherwarnings are received from users by the server, and the count of warningmessages exceeds a second threshold, then the server broadcasts a secondmessage to all of the users on the network instructing the anti-virusprograms located at each user computer to block the suspect data toprevent any onward transmission or infection.

Given the above overview, within the first embodiment each user computer15 contains a computer readable storage medium 22, as shown in FIG. 2.The computer readable storage medium will typically be a magnetic harddrive, or may equally be a DVD RAM, DVD−RW, DVD+RW, solid state memory,optical disc, magneto optical disc, or the like. The computer readablestorage medium 22 at each user computer 15 is arranged to store a datafilter program 24, and a warning receipt program 26. In addition,storage space is also provided for suspect data signatures and ID's,stored in the form of a data base 28.

The server 12 within the first embodiment also contains a computerreadable storage medium 32 which will typically be a magnetic hard disc,but may also be any of the storage devices mentioned previously inrespect of the or each user computer 15. Within the first embodiment thecomputer readable storage medium 32 stores a warning creation program34, and a suspect data signature and ID database 36. Optionally, thecomputer readable storage medium 32 may also store a data filter program38, to provide an alternative method of operation as will be describedlater.

Having described the main system hardware elements required by the firstembodiment, the operation thereof will now be discussed with referenceto the flow diagrams of FIGS. 4, 5, and 6.

Assume that a user computer 15 connected to the network 10 receives amessage over the network which contains a computer virus or the like(referred to hereafter as suspect data). Within the first embodiment ofthe invention a user of the user computer 15 upon reading the messagerecognises that the message contains such suspect data, and hence withinthe first embodiment then forwards the suspect data as the payload in awarning message of predetermined format to the server 12. By forwardingthe data as the payload encapsulated in a warning message of knownformat, the server knows that the payload is potentially suspect data,and hence will not become victim to the computer virus itself. At theserver, upon receipt of such a warning message from one of the usercomputers 15, the warning creation program 34 is run, and the stepsperformed by this program are shown in FIG. 4.

Firstly, at step 4.1 the server receives a warning message from one ofits clients, being one of the user computers 15 (as described above).Then, at step 4.2 the server parses the warning message to retrieve thesuspect data, and checks the message to see if it could be a computervirus. Such checking preferably takes the form of determining the datatype to see if it could feasibly be a virus. Viruses are frequentlyexecutable files, such as .exe or .bat on a PC, or macros such as arefound in Microsoft® Word® or Excel®. Such a check can conveniently beperformed by looking at any file extension on the data. If such checkingdoes not indicate that the data could be a virus then processing ends,as it is assumed that the user has simply made a mistake. Instead, ifthe warning message is in fact a true warning and the suspect data couldpossibly be a virus, then processing proceeds to step 4.3.

Note here that the checking step of step 4.2 is performed in thepreferred embodiment, but in other embodiments may not be performed, andas such is optional. Where step 4.2 is not performed processing proceedsdirectly from step 4.1 to 4.3.

At step 4.3 the server reads the suspect data from the payload, andcreates a “signature” for the suspect data, to permit the particularpiece or set of suspect data to be identified in the future. Such asignature may be conveniently created by running the suspect datathrough a hash function. Hash functions are well known in the art, andcommonly provide a 16 or 20 bit output word unique to any particularpiece or set of data input thereto. The key feature of hash functionswhich may be of use in the present invention, however, is that the sameoutput word is always output from the hash function for the same pieceor set of input data. Thus the hash value for a certain piece or set ofsuspect data will always be the same, no matter where the suspect datahas been received from.

It should be noted that other forms of signature creation other than theuse of hash functions may also be of use, the only requirement beingthat an identifiable unique signature is generated for any particularpiece or set of suspect data input into the signature creation functionat any time.

Following the creation of the data signature, at step 4.4 the signatureand ID database 36 is accessed to retrieve the first previously storedsignature and accompanying signature ID therefrom. The signature and IDdatabase 36 in the server 12 is used to store the generated signatureID's from pieces of suspect data received in previous warning messages.At step 4.4 the first signature and ID in the data base is retrieved thefirst time the controlling function for step 4.4 is called, andthereafter at succeeding calls the next signature and ID in the databaselist are successfully retrieved.

At step 4.5, the threat signature of the received suspect data generatedat step 4.3 is compared with the stored signature retrieved from thedatabase at step 4.4. If the threat signature is not the same as theretrieved stored signature then processing proceeds to step 4.11,wherein a check of the signature and ID database 36 is made to see ifall stored signatures have been compared with the new signature. If notthen processing proceeds to step 4.4, which retrieves the next signatureand ID from the database 36 for evaluation at step 4.5 with thegenerated data signature for the presently received.

If at step 4.11 it is determined that all of the stored signatures havebeen compared with the newly created threat signature then it must bethe case that the warning message received from the user computer atstep 4.1 is the first warning message from any of the user computers tobring to the server's attention the particular piece or set of suspectdata contained in the warning message payload. In this case it isnecessary for the server to store information on the suspect data, andthis is achieved by storing the suspect data signature created at step4.3 together with a new unique signature ID within the signature and IDdatabase 76. This storing function is accomplished at step 4.12, andthereafter processing proceeds to step 4.13, wherein a count of warningmessages received for the particular piece of suspect data isestablished, and initiated to a value of one. It will be appreciatedthat a separate count is maintained for every different piece or set ofsuspect data received in a warning message, and hence at any one timethe server will be maintained in several different counts. Therefore,conveniently the various counts may be maintained in a one dimensionalarray structure, indexed by the particular suspect data's signature ID.Such storage of the count is shown in step 4.13.

Following the storage of the data signature, signature ID, andestablishment of the message count for the suspect data, then in thecase that the suspect data had never been received before processingthen ends.

Returning to a consideration of step 4.5, if it turns out that theparticular piece or set of suspect data included in the warning messagehas been received before in a previous warning message then at somepoint in the loop formed by steps 4.4, 4.5, and 4.11, the evaluationperformed at step 4.5 will return a positive value, in that the threatsignature generated at step 4.3 will match a previously storedsignature. In this case processing then proceeds to step 4.6, whereinthe ID of the stored signature is used at an index into the signaturecount array, and the particular count for the stored signature isincremented by one to reflect the receipt of an additional warningmessage relating to the particular piece or set of suspect data to whichthe signature relates. Following the incrementing of the signaturecount, processing proceeds to step 4.7.

Step 4.7 represents the first thresholding evaluation performed todetermine whether or not a sufficient number of warnings have beenreceived from the user computers concerning a particular piece or set ofdata such that action should then be taken against that data. Therefore,at step 4.7 an evaluation is performed to determine whether thesignature count for the particular piece or set of suspect data isgreater than a “block” threshold value. If so processing proceeds tostep 4.10, wherein the server then broadcasts a message to all of theuser computers 15 on the network, the message containing the particulardata signature ID, and a message condition indicator field which in thiscase contains data instructing the user computers to block the suspectdata if it is received thereat. Blocking of the suspect data isperformed by the data filter program 24 provided at each user computer15, the operation of which is described later.

It should be noted that at step 4.10 the message from the server to theclients contained only the signature ID and the condition indicator anddoes not contain the actual signature itself. The reason for this isthat it is assumed that prior to any particular piece or set of suspectdata becoming blocked a warning message will have been transmitted fromthe server to the User computers containing the suspect data signature,and hence there is no need to retransmit the signature at step 4.10.

If the evaluation at step 4.7 returns a negative, processing proceeds tothe evaluation at step 4.8 wherein the signature count for theparticular piece or set of suspect data is compared against a warningthreshold level. It should be noted here that the warning thresholdlevel is set less than the block threshold level such that theevaluation of step 4.8 is always found positive before the evaluation ofstep 4.7. If the evaluation of step 4.8 returns a negative such that thecount is less than the warning threshold then this means that not enoughwarning messages have been received from user computers concerning theparticular piece or set of suspect data such that no action should betaken as yet. In this case processing of the warning creation program 34then ends.

In contrast, if the evaluation at step 4.8 is positive, the processingproceeds to step 4.9 wherein the server broadcasts a message over thenetwork to all the user computers 15, the message containing the suspectdata's signature as generated at step 4.3, a new data signature ID,being simply an identifier of the signature which can be used as a shorthand means of identifying the particular piece or set of suspect data,as well as a “warn” flag in a data condition field of the message. Thepresence of the warn flag in the data condition field of the messagecauses the data filter program 24 at the user computer to warn the userwhenever the suspect piece of data is received, as will be describedlater. Following the broadcast of the warning message at step 4.9,processing by the warning creation program 34 ends.

The output of the warning creation program 34 is therefore a warningmessage broadcast to all the user computers 15 instructing the usercomputers to upgrade their threat levels for a particular piece or setof suspect data provided that enough warning messages have been receivedat the server concerning the particular suspect data. At each usercomputer upon receipt of a warning message from the server the warningreceipt program 26 is run, and the steps performed thereby are shown inFIG. 5.

With reference to FIG. 5, at step 5.1 a warning message containing theinformation described earlier is received from the server. Followingthis, at step 5.2 the user computer 15 passes the warning message todetermine whether or not the message contains a data signature.

If the message does not contain a data signature, then this means that awarning message must have been received at some point in the past fromthe server containing the data signature, and therefore the datasignature will be already stored in the ID database 28 at the usercomputer 15. In this case processing proceeds to step 5.4, wherein thesignature ID contained within the received warning message is used toindex and retrieve the appropriate signature from the database 28,whereupon processing then proceeds to step 5.6.

At step 5.6 the data condition indicator which is contained in thewarning message received from the receiver is read, and a conditionfield in the database 28 related to the particular suspect datasignature is updated to match the condition indicated in the warningmessage from the server. In this case, as a warning message will havealready been received concerning the particular suspect data and hence a“warn” condition already set, it is likely that the condition is beingupdated to a “block” condition. Following step 5.6 the processing by thewarning receipt program ends.

If at step 5.2 it is determined that the warning message from the serverdoes contain a data signature, then this will be the first warningmessage received from the server concerning the particular suspect data.In this case, processing proceeds to step 5.3 wherein the receivedsignature is stored in the database 28 indexed by the ID which is alsocontained in the received message. Furthermore, a condition field in thedatabase related to the signature is also set, at step 5.4. In thiscase, as this will be the first warning message received from the serverabout the particular suspect data the condition will be set to a “warn”condition. Following step 5.4 the processing by the warning receiptprogram 26 ends.

It has thus been described how users can generate warnings about suspectdata which are then transmitted to the server, which then broadcastswarnings to all users if enough user's specific warnings have beenreceived. Users can then record the particular security advice broadcastfrom the server concerning a piece or set of suspect data, and we nowdescribe how user computers 15 may use the broadcast warnings within thedata filter program 24.

More particular, as mentioned previously each user computer 15 isprovided with a data filter program 24 which is arranged to run in thebackground of the computer all the time the computer is operating in asimilar manner to anti-virus and other security programs of the priorart. The data filter program 24 acts to monitor all data received at theuser computer 15 upon which it is stored to determine if any of thereceived data matches the signatures of any suspect data stored in thesignature and ID database 28. The steps performed by the data filterprogram 24 in performing this function are shown in FIG. 6.

At step 6.1 assume that the user computer 15 has received some data inthe form of an email message or the like over the network 10. At step6.2 the data filter program 24 acts to create a signature of thereceived data using the same signature generation function as is used inthe server 12. That is, the signature of the received data may becreated using a hash function or indeed any other signature generatingfunction which provides a repeatably generatable unique signature for agiven set of input data.

Following the creation of the data signature, at step 6.3 the signatureand ID database 28 at the user computer 15 is accessed and the firstsignature and signature ID within the database is retrieved therefrom.Upon subsequent calls to the controlling function of step 6.3 the nextsignature and signature ID in the database list is retrievedsuccessively.

Following step 6.3 processing proceeds to the evaluation of step 6.4,wherein the data signature created at step 6.2 is compared with theretrieved signature from the database 28. If these signatures do notmatch then processing proceeds to the evaluation of step 6.10, whereinthe database is again accessed to see if all signatures have beenaccessed and compared. If at step 6.10 it turns out that all of thesignatures stored in the database have been compared against thesignature of the received data and no match has been found, then it canbe concluded that the received data is not suspect data, and hence thedata filter program ends. In such a case the user is then free to usethe received data in whatever manner she chooses.

In contrast, if at step 6.10 it is determined that not all of the storedsignatures have been compared against the received data signature,processing returns to step 6.3 wherein the next stored signature and IDin the database are retrieved, and the evaluation of 6.4 is performedonce again.

If at step 6.4 it is determined that the received data signature is theequivalent of a previously stored signature then processing proceeds tostep 6.5. Here, the database is again accessed to retrieve the signaturecondition associated with the stored signature to determine whatsecurity condition was attached to the signature by the server in thelast warning message received from the server concerning the particularsignature. Following step 6.5 the retrieved condition is checked at step6.6 to see if it is a “warn” condition, and if so processing proceeds tostep 6.7, wherein a warning is displayed on the user computer's screento warn the user about the received data. Following the display of thewarning the particular process performed by the data filter program 24ends, although it should be noted that the data filter program willcontinue to run continuously in the background to check whenever data isreceived.

If the retrieved signatory condition is not a “warn” condition thenprocessing proceeds to the evaluation of step 6.8 wherein the conditionis checked to see if it is a “block” condition. If so then at step 6.9the data filtering program 24 acts to block the receipt of the suspectdata either by preventing the computer from downloading it from theserver or from merely deleting it from the user computer's localstorage, and again the user is preferably informed of this action.Following this action the processing performed by the data filterprogram 24 ends, although again the program will continue to run in thebackground to detect the receipt of new data.

If the evaluation of step 6.8 does not indicate that the retrievedsignature is a “block condition”, then the data filter program 24processing ends, and the program returns to running in the background,as described previously.

The first embodiment of the invention therefore presents a computersecurity system whereby computer viruses and the like can be detected byindividual users, who transmit warnings to a server which thenbroadcasts warnings as appropriate to all users if the number ofindividual warnings received from individual users exceeds certainthresholds. The use of thresholding in the server instils in theinvention a degree of order, in that it is only once a particularthreshold level of warnings have been received that action is taken bythe server and user computers against the suspect data. This prevents,for example, inexperienced users who may mistake acceptable data forsuspect data from initiating a security alert on the acceptable datawhich may prevent other users from receiving that data, for example.

Furthermore, the threshold levels for both the “warn” and “block”conditions may of course be set at any level required, and may even besimply one. The assumption is made, however, that in order for theembodiment to operate in a meaningful manner the warn threshold is lessthan or equal to the block threshold.

Within the preferred embodiment we have described the data filterprogram 24 as being located at each of the user computers 15 and runningthereat. However, in a slight variation of the first embodiment it wouldof course be possible for the data filter program 24 to also run at theserver to screen messages and data routed therethrough. In this case theoperation of the data filter program would be exactly the same aspreviously described with respect to FIG. 6, however it would mean thatthe user computers 15 would neither need the data filter program 24, thewarning receipt program 26, or the signature and ID database 28, as allblocking operations could be performed centrally. However, in the casethat it is desirable for users to be warned about data to be received,then it will still be necessary to have the data filter program 24,warning receipt program 26, and signature and ID database 28 at the usercomputer 15 as described previously in order to allow such warnings.

In another variation of the first embodiment, in another embodiment astep equivalent to step 4.2 can be performed at the user computersbefore a warning message is generated. Here, after a user has identifieda piece of data as suspect and instructed her computer to send a warningmessage to the server, prior to compiling and sending the message thewarning creation program 34 controls the computer to check if the dataidentified as suspect by the user could possibly be a virus. Suchchecking is substantially identical to the check performed at step 4.2,i.e. takes the form of determining the data type to see if it couldfeasibly be a virus. Viruses are frequently executable files, such as.exe or .bat on a PC, or macros such as are found in Microsoft® Word® orExcel®. Such a check can conveniently be performed by looking at anyfile extension on the data. If such checking does not indicate that thedata could be a virus then no warning message is sent, as it is assumedthat the user has simply made a mistake. Instead, if the data is of adata type which could be a virus (e.g. an executable or the like) thenthe warning message is transmitted.

The primary advantage of the first embodiment which makes use of theserver to keep track of the number of warning messages received about aparticular piece of suspect data is that the network traffic overheadintroduced by the security system is minimised, as users need only sendwarning messages to the server, which can then broadcast warningcondition messages as appropriate.

A second embodiment of the invention will now be described withreference to FIGS. 7 to 10.

The second embodiment of the invention presents a pure “peer to peer”system which does without the server 12 of the first embodiment.Instead, within the second embodiment each user computer 15 itselfindividually keeps count of the number of warning messages received fromits peers concerning suspect data, and in turn when a user computerdetects suspect data it generates and broadcasts a warning message toall of its peers. This arrangement has the advantage that it is notdependent upon a central server for operation, and is therefore muchmore robust and immune to the loss of one or more of its elements thanthe client-server architecture of the first embodiment.

FIG. 7 illustrates the software elements present at a user computer 15in the second embodiment of the invention. More particularly, as in thefirst embodiment the user computer 15 is provided with a computerreadable storage medium 22 on which is stored a data filter program 24,a warning creation program 72, a warning receipt program 74, and asignature and ID database 76.

Within the second embodiment the data filter program 24 and the warningcreation program 72 both continuously run in the background on the userscomputer at all times. The data filter program 24 operates in exactlythe same manner as previously described in the first embodiment withrespect to FIG. 6, that is it acts to check the signature of receiveddata against signatures of suspect data stored in the signature database76, and takes action against any received suspect data as necessary. Inthis respect, the operation of the second embodiment is exactly the sameas that of the first embodiment. The difference between the secondembodiment and the first embodiment lies, however, in the fact that eachuser computer 15 directly broadcasts warnings to each of its peercomputers (i.e. the other user computers 15), and in addition each usercomputer 15 also keeps its own track of the count of warning messagesreceived against each piece of suspect data. These functions areperformed by the warning creation program 72 and the warning receiptprogram 74, as described next.

The operation of the warning creation program 72 is shown in FIG. 8.Here, at step 8.1 data is received at the user computer 15 over thenetwork 10. At step 8.2 an evaluation is performed to determine whetherthe received data is a security threat or not. As with the firstembodiment, this evaluation is preferably performed by the actual humanuser of the computer 15 who employs her expertise to determine whetheror not the received data is a computer virus or the like. In alternativeembodiments, however, it may be that this evaluation could be performedby a software agent installed on the users computer, the software agentacting to monitor the functions of the computer to determine if it isunder attack from a computer virus. Within the first and secondembodiments, however, we prefer the use of a human operator to performthe evaluation.

If the evaluation at step 8.2 concludes that the received data is not athreat then the processing performed by the warning creation program onthe received data ends and the program returns to running in thebackground until further data is received in the future.

If it is determined at step 8.2 that the received data is a threat, thenat step 8.3 a data signature for the received data is created. As in thefirst embodiment, the signature generation function may be a hashfunction or the like or any other suitable signature generation functionwhich is capable of repeatably generating the same signature for a givenset of input data. Furthermore, it should be noted here that each usercomputer 15 must use the same signature generation function, such thatwhen the same set or piece of suspect data arrives at any of the usercomputers, each of them creates the same signature therefor.

At step 8.4 a check is made to see whether the generated data signaturehas already been stored in the signature and ID database 76, and if notthen at step 8.8 the signature is stored in the database, and isallocated a globally unique ID. The ID for the signature is generated bythe user computer, preferably from a list of ID's which have beenspecifically allocated to that user computer for allocation tosignatures thereby.

Following step 8.8, at step 8.9 a message count is instantiated for theparticular signature generated by the received data, and is set to thevalue one. As in he first embodiment, the various count values for eachpiece of suspect data may be stored in a one dimensional array indexedby signature ID.

Following step 8.9 at step 8.10 the warning creation program causes theuser computer to broadcast the data signature and the signature ID toall of its peers as a warning message. As in the first embodiment, thewarning message preferably takes a known format, with the signature andsignature ID as particular fields within the warning message. Followingthe broadcast of the warning message, at step 8.10 processing of thewarning creation program ends, and it returns to run in the background.

Returning to the evaluation at step 8.4, if it is determined that thedata signature for the received data has already been stored (i.e. thedata has already been identified as suspect by either the present user,or one of the other users who have then broadcast a warning messagewhich has been received at each user computer) then processing proceedsto step 8.5, wherein the message count maintained for the particularsignature is incremented to reflect the fact that the data has in factbeen identified once again as a threat.

Next, at step 8.6 the signature ID is broadcast to every other user inthe system as part of a warning message, and then following that at step8.7 the appropriate warning or block conditions are set for thesignature based on the warning and block threshold values. The specificoperations required by step 8.7 are shown in more detail in FIG. 10.

With reference to FIG. 10, the steps required for setting the warning orblock conditions for a particular data signature are as follows. At step10.1 the message count for the particular data signature is retrieved,by indexing into the counter array using the signature ID. Then, at step10.2 the retrieved message count is compared against the blockthreshold, and if larger than the threshold at step 10.3 the securitycondition for the data signature is set to “block”. As in the firstembodiment, this security condition is stored in the signature and IDdatabase 76, and is used by the data filter program 24 to filterreceived data.

If the warning message count for the particular data signature is notgreater than the block threshold then the message count is comparedagainst the warning threshold. If it is not greater than the warningthreshold then no warning or block condition is set for the particulardata signature. In contrast, if it is greater than the warning thresholdthen the security condition for the particular data signature is set to“warn”, which is again used by the filter data program 24 as describedbefore in respect of the first embodiment.

Returning to FIG. 8, once the warning or block conditions have been setfor the data signature, the specific processing performed by the warningcreation program 72 ends, and it returns to running in the backgrounduntil further data is received.

Turning now to the operation of the warning receipt program 74, thisprogram operates whenever a warning message generated by a warningcreation program stored on another user's computer is received. Theoperation of the warning receipt program 74 is shown in FIG. 9.

At step 9.1, a warning message is received from one of the other usercomputers. The warning message is of course in a predetermined formatwhich identifies it as such. Then, at step 9.2 the warning receiptprogram 74 acts to parse the message to see if it contains a datasignature relating to suspect data. Recall here that the data will havebeen determined as suspect by the user of the user computer from whichthe message was received. If it is determined that the message does notcontain a signature, then this means that the data will have alreadybeen determined as suspect previously, and hence should already bestored in the user computer's signature and ID database 76. Therefore,at step 9.3 the warning receipt program acts to retrieve the messagecount for the particular suspect data to which the warning messagerelates, using the signature ID which will have been included in thewarning message (recall here that at step 8.6 in the warning creationprogram where the suspect data has already been identified as such awarning message is still sent out including the suspect data signatureID). Then, at step 9.4 the retrieved message count for the suspect datais incremented to reflect the additional warning, and at step 9.5 thewarning or block conditions for the data signature are also set,following the procedure of FIG. 10, as described previously.

If it is determined at step 9.2 that the message does contain asignature, then processing proceeds to the evaluation of step 9.6wherein it is determined whether or not the received signature hasalready been stored. If not processing proceeds to step 9.7 wherein thesignature is stored in the signature and ID database 76 indexed by thesignature ID included in the received warning message. At step 9.8 amessage count is instantiated for the newly stored data signature, andis set to one. As described previously, the count values for eachparticular signature can be stored in a one dimensional array, indexedby each signature ID.

Following step 9.8 processing proceeds to step 9.5, wherein the warningor block conditions are set for the particular signature, using theprocedure of FIG. 10.

Returning to step 9.6, if it is determined that the signature receivedin the warning message has already been stored then processing proceedsto step 9.9, wherein the received signature ID is stored for use asanother key to the signature.

In such a case a count value should be instantiated related to thereceived signature ID, with its value set to the same value as the countindexed by the ID of the already stored signature which matches thereceived signature. Then, at step 9.10 both of the count values storedfor each ID (the received ID, and the ID of the previously stored IDwhich matches the received signature) are incremented to reflect thereceipt of the additional warning. Finally, following the increment ofthe message counts for the signature the warning and block conditionsare set for the signature once more, using the procedure of FIG. 10.

Therefore, as described the second embodiment provides a pure peer topeer system which incorporates the distributed warning capabilities ofthe security system of the present invention with the ability tothreshold the warnings so as to be able to provide a graded reactionlocally at each user computer. The provision of such a peer-to-peeroperation provides for a more robust system, but as mentioned earliermight have detrimental network overheads due to the need to broadcastevery warning message to every user.

As a modification to the operation of the second embodiment, anadditional checking step analogous to step 4.2 of the first embodimentmay be performed between steps 8.2 and 8.3 of FIG. 8 depicting theoperation of the warning creation program 72. Here, after the human userhas identified data as suspect at step 8.2, an additional check is madeto see if the data could possibly be a computer virus. Such checkingpreferably takes the form of determining the data type to see if itcould feasibly be a virus. Viruses are frequently executable files, suchas .exe or .bat on a PC, or macros such as are found in Microsoft® Word®or Excel®. Such a check can conveniently be performed by looking at anyfile extension on the data. If such checking does not indicate that thedata could be a virus then processing ends, as it is assumed that theuser has simply made a mistake. Instead, if the warning message is infact a true warning and the suspect data could possibly be a virus, thenprocessing proceeds to step 8.3, and onwards as previously described.The operation of the other programs in the second embodiment remainsunchanged.

It should be noted here that as the second embodiment does not require aserver to act centrally, but rather is a true peer-to-peer system, it isparticularly suitable for implementation on networks such as ETHERNETand the like.

Various further modifications may be made to either of the first orsecond embodiments to produce further embodiments, as described next.

In further embodiments it is possible to add more sophistication toincrease the power of the system. For example, users could be given theability to respond to a warning to inform the server of whether theyagree with the assessment or not—this would give the potential ofreducing the count number if appropriate. The decision as to whether aparticular program was a threat or not would then be a collectivedecision from the whole community.

Furthermore it is also possible to build in trust models for each usersuch that some users have greater influence than others. Such trustmodels could be pre-defined according to the users position within thecommunity/organisation, such that a warning received from a user with ahigh trust rating increments the signature count for a particular pieceor set of suspect data more than another user with a lower trust rating.Each trust model may then also be adaptively varied by judging theaccuracy of a prediction that a user has made against a final collectivedecision, and any further warnings registered by that user could beweighted according to the trust in that users demonstrateddecision-making ability.

In other embodiments a community of organisations could be formed thatwould extend the collaboration beyond the limits of a singleorganisation through sharing of knowledge. Any discoveries in oneorganisation could be passed on to all other organisations in thecommunity and vice versa. This would greatly extend the power of thesystem and in many cases allow rapid response to intrusions experiencedin other organisations without any internal hits being experienced tothe remaining organisations using the system.

Moreover, in another embodiment the actual number of warnings receivedconcerning a particular piece or set of suspect data could be displayedto the user if the suspect data is received at the user's computer, andthe user could then decide what action to take himself. Such a scheme isakin to the “warn” action of the primary embodiments, but provides theuser with the additional information of how many other users havedetermined the data to be threat, thus providing the user with anassessment analogous to a community “confidence-level” in the data, sucha level being of greater resolution than the simple “warn” or “block”conditions. Furthermore, such a scheme would not require the system toactually perform automatic blocking of suspect data, as this could beleft to the user to do himself. This mode of operation provides theadditional potential advantage that a highly skilled or confident usermay not wish to act on the community warning if he is sure that it maybe wrong, thus increasing the flexibility of the system.

Furthermore, in another embodiment based on the peer-to-peerarchitecture of the second embodiment, rather than broadcast to allpeers e.g. all users in BT—sub-communities of peers are formed so thatthe initial broadcasting of warning messages concerning a particular islimited to a smaller number of peers. An example of such an architectureis shown in FIG. 11, whence it will be seen that a plurality ofsub-communities 111, 112, 113, and 114 may be provided, each connectedto each other. Only when the count passes the warning threshold in oneof the sub-communities is the suspect data signature distributedfurther. This limits the overheads incurred by false positives in thatany particular sub-community would need to agree that a particular pieceor set of data was a threat before it was broadcast to the widercommunity. “Crossover points” are provided between the sub-communitiesso that inter-group (or alternatively “inter-community”) warnings may bepassed on to other sub-communities by the provision of one of the peers115 in a particular sub-community acting as the bridge via acommunications link to another peer in a neighbouring sub-community, andonly communicating with that other peer when the warning (or block)threshold has been passed in its own parent sub-community i.e. thesub-community has decided that the particular piece or set of suspectdata really could be a threat.

The processing steps involved in such an embodiment are almost identicalto those required in the second embodiment, with the addition that theprocessing steps depicted in FIG. 10 are altered to include anadditional step after step 10.3 or 10.5 wherein once the filtercondition has changed (as a consequence of either step 10.3 or 10.5) ifthe computer is a bridging peer to another sub-community then aninter-group warning message is sent to the connected sub-communityinforming the other peer that a change in the filter condition hasoccurred for a particular piece or set of suspect data. Such aninter-group warning message should preferably include at least the datasignature, as well as a warning condition indicator to communicate thethreat level (e.g. warn or block) decided by the sending sub-community.By sending such a warning message to other sub-communities, the bridgingpeer is effectively declaring to the other sub-communities to which itis connected that its peers in its own sub-community have found thesuspect data identified in the warning message to be a security threat.

Conversely, when an inter-group warning message is received at abridging peer from another sub-community, the bridging peer shouldbroadcast the inter-group warning message onwards to all its own peersas an intra-group message, to inform them of the threat assessment madeby the neighbouring community. Each peer can then store the suspect datasignature in its signature and ID database 76, for future reference bythe data filter program 24 as needed (and in the same manner as alreadydescribed in relation to the second embodiment).

Whether or not a user computer in a sub-community uses a forwardedinter-group warning message directly to initiate action (such as “warn”or “block” for the indicated suspect data) is optional, as it could bethat it may wish to wait until it's own community has also agreed onaction in respect of the same suspect data before actually initiating a“warn” or “block” condition for the data. Conversely, where a particularuser-computer's own sub-community has already come to agreement on aparticular piece or set of suspect data (i.e. either the “warn” or“block” threshold has been passed), then it may be that theuser-computer may wish to wait until one or more connectedsub-communities have also made the same finding before setting theappropriate condition in its database for the data. It will be apparentthat there are a multitude of possibilities as to when any particularuser computer may wish to actually set an action condition for aparticular piece or set of suspect data. For example, an actioncondition may be set for a particular piece or set of suspect data onlyif a user computer's own sub-community has agreed on the action inaddition to a threshold number of other sub-communities, oralternatively if merely a threshold number out of the total number ofsub-communities has agreed on the action regardless of the particularuser computer's own sub-community's finding. Other such alternativesrepresenting possible combinations of the logical conditions required inorder to set an action condition will be apparent to the intendedreader.

It is clear that such an architecture of sub-communities is analogous toa plurality of inter-connected local area networks, although it is notessential that each peer in a particular sub-community need actually belocated in the same actual LAN (although this may be preferable). Thisis because all that defines any particular sub-community is the commoncause that upon detecting suspect data a user broadcasts a message toall of its peers in the same sub-community, and hence all that isrequired is some message transport mechanism between peers. Such amessage transport mechanism may be a single LAN to which all the peersare connected, or may be a sequence of interconnected networks such asthe Internet, with different peers in a sub-community actually beingpart of different networks.

The modification to the second embodiment to split the user computersinto sub-communities provides the additional advantage over the basicsecond embodiment that it, at least partially, overcomes the primarydisadvantage of the high signalling bandwidth which would be requiredfor the transmission of the warning messages to every other peer, andhence allows for scalability to add more users. As an example, considerthe case where a community consists of n peers, such that when a warningmessage is broadcast from one of them to each of the others (n−1)individual intra-group warning messages are sent. Now, assume that inorder to agree on action about a particular piece or set of data aproportion of 1/a peers have to agree i.e. the action threshold is n/a.In such a case a total of n(n−1)/a intra-group warning messages have tobe transmitted in total for any one particular piece or set of data.Thus, where there are 40 peers, and half of them have to agree beforeaction can be taken, a total of 780 warning messages would have to betransmitted (without error) before the action is agreed upon.

Now consider that the community of n peers is split equally into xsub-communities, as shown in FIG. 11. In this case, within asub-community for any single warning from one peer a total of (n/x−1)intra-group warning messages are broadcast. Assuming that in order toagree on action about a particular piece or set of data a proportion of1/a peers have to agree i.e. the action threshold is n/ax, then a totalof n(n−x)/ax² intra-group warning messages have to be broadcast within asingle sub-community for action to be agreed on a single piece ofsuspect data. Assuming that each sub-community has to reach agreementwithin itself and communicate to each other group that it has so agreedbefore action can be taken by any peer in any sub-community, there willstill only be a total of n(n−x)/ax intra-group warning messagesbroadcast in total (the sum of the number of warning messages in totalbroadcast in each sub-community), plus x(x−1) inter-group messagesbetween sub-communities, plus (n/x−1) further intra-group messages fromthe bridging peer in each sub-community to each other peer in itsrespective community informing them of the findings of othersub-communities (i.e. forwarding received inter-group messages onwards).Note that with respect to this latter number of intra-group messages,(n/x−1) messages are sent from a bridging peer in a sub-community foreach inter-group warning message received from another sub-community,such that where full knowledge of every other sub-community's findingsabout a particular piece or set of suspect data is required to bedisseminated throughout a particular sub-community, the total number ofintra-group messages transmitted by a single bridging node forwarding onthe findings of other sub-communities would be (x−1)(n/x−1). This leadsto the total number of intra-group messages forwarding inter-groupmessages across the entire community of users of x(x−1)(n/x−1).

For example, if there are 40 peers split into 2 sub-communities of 20,then in each sub-community 190 messages are sent before action is agreed(i.e. the action threshold is reached) in each sub-community, 2 messagesare exchanged between the respective bridging peers of eachsub-community, one in each direction, and then the respective bridgingpeers each send 19 messages to inform their own peers of the finding ofthe other sub-community, to give a total of 420 messages. This issubstantially less than the 780 messages which were required when thepeers were not split into sub-communities.

It should be apparent that the above numeric examples are dependentsolely on the logical conditions which were ascribed to the groupoperation, and in particular in the example above the need for everysub-community to agree on action about a particular piece or set of dataand each issue its own inter-group warning message before any action istaken. Where slightly lower thresholds are set for action (e.g. if onlyhalf the number of sub-communities are required to agree), then thenumber of both inter- and intra-group warning messages which would berequired to be broadcast before action is agreed would be furtherreduced.

In any of the embodiments of the invention described above and in otherembodiments not described it should be noted that the one or more“threshold values” against which the respective counts for pieces orsets of suspect data are compared may be any value, including zero, andmay be fixed or dynamically adaptive. Furthermore the actual values maybe generated by any appropriate function, such as for example by arandom number generator, or as a function of some metric of accuracy ofusers in identifying viruses. Furthermore, it is foreseen that thethreshold values may not simply be actual numbers which the respectivecounts must be greater than, but could instead be probabilistic innature. Furthermore, various logical functions or rules can be used fortheir creation, including for example, fuzzy logic. The threshold valuesmay therefore be any values, derived by any function or method, and arenot limited to the particular examples of threshold values given in thespecific embodiments described herein.

As described, the present invention therefore provides a collaborativecomputer security system wherein a distributed decision is takeninvolving all or substantially all of the users of the system, toeffectively allow the users to “vote” on whether or not a particularpiece or set of suspect data is a threat. By providing such adistributed system the response time to a computer virus attack can beimproved over the prior art case where a central authority is requiredto perform analysis and take action, thereby reducing the potentialdamage which may be caused by such an attack.

1. A computer security system for use in a network environmentcomprising at least a first group of user computers arranged tocommunicate over a network, the system comprising a warning messageexchange system operable to allow the communication from the usercomputers of warning messages relating to suspect data identified as apossible security threat; a message counting system operable to maintaina count for every particular piece or set of suspect data based on thenumber of warning messages communicated relating thereto; and networksecurity means operable to act in respect of any particular piece or setof suspect data for which the count maintained therefor is substantiallyequal to or greater than at least one threshold value.
 2. A computersecurity system according to claim 1, wherein the judgement as towhether any piece or set of data present at any one or more of the usercomputers is a possible threat is performed by the respective human useror users of the or each user computer.
 3. A computer security systemaccording to claim 1, wherein the network security means is furtheroperable to compare the maintained count for a particular piece or setof suspect data against a plurality of different thresholds, and to takedifferent action in respect of the data dependent upon which thresholdor thresholds are met.
 4. A computer security system according to claim1, wherein the action taken by the network security means compriseswarning each of the users as to the suspect nature of a particular pieceor set of data.
 5. A computer security system according to claim 1,wherein the action taken by the network security means comprisespreventing the transmission of the particular piece or set of suspectdata across the network.
 6. A computer security system according toclaim 1, wherein the or each warning message comprises at least anidentifier of the piece of or set of suspect data to which it relates.7. A computer security system according to claim 6, wherein theidentifier is the piece or set of suspect data itself.
 8. A computersecurity system according to claim 6, wherein the identifier is arepeatably generatable signature substantially unique to the piece orset of data.
 9. A computer security system according to claim 1, andfurther comprising a network server arranged to receive the or eachwarning message communicated from the user computers, and furtherarranged to host the message counting system and at least part of thenetwork security system, wherein that part of the network securitysystem hosted by the server is operable to determine the action whichshould be taken against a particular piece or set of suspect data, andto communicate an action condition indicator indicative of thedetermined action to each of the plurality of users.
 10. A computersecurity system according to claim 1, wherein a warning messagegenerated by a user computer is broadcast to every other user computer,and each user computer is further arranged to host its own messagecounting system and network security system operable in accordance withany of the preceding claims.
 11. A computer security system according toclaim 1, and further comprising an inter-group communications systemoperable to allow the communication of warning messages relating tosuspect data identified as a possible security threat from the firstgroup of user computers to one or more other groups of other usercomputers.
 12. A computer security system according to claim 11, whereinthe inter group warning messages are transmitted by the inter-groupcommunications system if the number of warning messages communicated bythe user computers in the first group concerning a particular piece orset of data is substantially equal to or greater than at least onethreshold value.
 13. A computer security system according to claim 12,wherein the threshold value or values is/are the same as those at whichthe network security system takes action.
 14. A computer security systemaccording to claim 11, wherein the inter-group communications system isfurther arranged to receive inter-group warning messages from the one ormore other groups of user computers.
 15. A computer security systemaccording to claim 14, and further comprising a second message countingsystem operable to maintain a count for every particular piece or set ofsuspect data based on the number of inter-group warning messagescommunicated relating thereto; and wherein the network security means isfurther operable to act against any particular piece or set of suspectdata for which the count maintained therefor by the second messagecounting system is substantially equal to or greater than at least oneinter-group threshold value.
 16. A computer security system according toclaim 15, wherein the network security means is further arranged to actagainst a particular piece or set of suspect data only if both therespective counts maintained by the message counting system and thesecond message counting system are substantially equal to or greaterthan at least the threshold value and the inter-group threshold valuerespectively.
 17. A computer security system according to claim 1,wherein the message counting system is further arranged to store one ormore weighting coefficients relating to one or more particular usercomputers, and to increment the count maintained for a particular pieceor set of suspect data by an amount based upon the weighting coefficientwhen a warning is received from the one or more particular usercomputers relating to the particular piece or set of suspect data.
 18. Acomputer readable storage medium storing one or more computer programswhich when run on a computer causes the computer to operate in themanner of a system according to claim 1.